Summary

This PR improving DataDog metric shipping, this way filtering/grouping is much easier.

• Introducing awslimitcheckr.usage and awslimitchecker.limit instead of awslimitchecker.service_group.service_name.limit / usage

• max_usage actually is the actual usage, that's why is replaced for datadog

• Here is an example output generated by the following command what should be sent to DataDog.

awslimitchecker \
     --metrics-provider Datadog \
     --metrics-config=api_key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
     --metrics-config=extra_tags=env:eu-west-1.test,stage:test \

....
    {
      "metric": "awslimitchecker.usage",
      "points": [
        [
          12546,
          0
        ]
      ],
      "type": "gauge",
      "tags": [
        "region:eu-west-1",
        "env:eu-west-1.test",
        "stage:test",
        "service:apigateway.api_keys_per_account",
        "service_group:apigateway",
        "apigateway"
      ]
    },
    {
      "metric": "awslimitchecker.limit",
      "points": [
        [
          12463,
          10
        ]
      ],
      "type": "gauge",
      "tags": [
        "region:eu-west-1",
        "env:eu-west-1.test",
        "stage:test",
        "service:apigateway.api_keys_per_account",
        "service_group:apigateway",
        "apigateway"
      ]
    },
...

This way can be selected and group by service_group, service, env, stage (tags on aws: from, over, sum by)

Contributor License Agreement

By submitting this work for inclusion in awslimitchecker, I agree to the following terms:

• The contribution included in this request (and any subsequent revisions or versions of it)
  is being made under the same license as the awslimitchecker project (the Affero GPL v3,
  or any subsequent version of that license if adopted by awslimitchecker).
• My contribution may perpetually be included in and distributed with awslimitchecker; submitting
  this pull request grants a perpetual, global, unlimited license for it to be used and distributed
  under the terms of awslimitchecker's license.
• I have the legal power and rights to agree to these terms.

Pull Request Checklist

• All pull requests should be against the develop branch, not master.
• All pull requests must include the Contributor License Agreement.
• Whether or not your PR includes unit tests:
  • Please make sure you have run the exact code contained in the PR locally, and it functions as desired.
  • Please make sure the TravisCI build passes or, if not, you've corrected any obvious problems identified by the tests.
• Code should conform to the Development Guidelines:
  • pep8 compliant with some exceptions (see pytest.ini)
  • 100% test coverage with pytest (with valid tests). If you have difficulty
    writing tests for the code, that's fine, just mention that in the summary and either
    ask for assistance, or clarify that you'd like someone else to handle the tests. PRs that
    include complete test coverage will usually be merged faster.
  • Complete, correctly-formatted documentation for all classes, functions and methods.
  • documentation has been rebuilt with tox -e docs
  • Connections to the AWS services should only be made by the class's
    connect() and connect_resource() methods, inherited from
    awslimitchecker.connectable.Connectable
  • All modules should have (and use) module-level loggers.
  • Commit messages should be meaningful, and reference the Issue number
    if you're working on a GitHub issue (i.e. "issue #x - "). Please
    refrain from using the "fixes #x" notation unless you are sure that the
    the issue is fixed in that commit.
  • Git history is fully intact; please do not squash or rewrite history.